Generally, the present application relates to access management. More specifically, the application is related to techniques for protecting against denial of access by accounts providing access to resources.
Modern businesses rely on a variety of applications and systems that control and generate information that is critical to business operations. Different applications often provide different services and information, and different users may require access to different levels of information within each system or application. The level of access that users are granted may depend on the role of the user. For example, a manager may need access to certain information about employees that report to him, but it may be improper for that manager to access the same information about those whom he reports to.
Earlier less sophisticated applications incorporated access management business logic directly into the application code. That is to say, each application would require users to have a separate account, separate policy logic, and separate permissions, for example. Furthermore, when a user is authenticated by one of these applications, this authentication remains unknown to other applications in the enterprise because the fact that authentication with the first application has taken place is not shared. Thus, there is no concept of trust between applications using different systems for authentication and access control. Engineers quickly realized that having an access management system for each application in an enterprise was much like having a gas station for each car, and determined that authentication and access control would be more efficiently implemented and managed as a shared resource. These shared resources became known as an access management systems.
Access management systems often use policies and other business logic to make a determination regarding whether a particular access request should be granted to a particular resource. Upon making a determination that access should be granted, a token is provided to a client (e.g., client application at a device) of the requestor. This token is like a key that can be used to open a door that guards restricted data. For example, a user may attempt to access a human resources database to gather information about certain employees such as salary information. The user's web browser at a client makes a request to the application, which requires authentication. If the web browser does not have a token, the user is asked to log in to the access management system. When the user is authenticated, the user's browser at the client receives a token that may be used to access the human resources application.
In an enterprise, users (e.g., employees) typically may have access to one or more different systems and applications. Each of these systems and applications may utilize different access control policies and require different credentials (e.g., user names and passwords). A user wanting to access multiple resources protected by an access management system may need to be authenticated by credentials provided to the access management system. A successful authentication gives the user authorization to access the protected resources, based on their assigned access privileges.
If a user wants to access multiple resources protected the access management system, the access management system may determine whether the user is authenticated to access the multiple resources requested by a user. In some instances, authentication of a user for one resource may suffice for accessing other resources, otherwise the access management system may request additional credentials from the user. Upon authentication to access multiple resources, the user may not need to re-authenticate to access additional resources. In such instances, the access management system may maintain a single session, such as a single sign-on session (SSO), which provides a user with access to multiple resources after authentication.
Regardless of a type of session, an access management system may prevent brute-force discovery of user passwords for a user's account. For example, an access management system may prevent a user from gaining access to a user's account (i.e., by locking the user's account) upon determining that the user has attempted to gain access a threshold number of times. A user who does not own the account can cause the access management system to lock a genuine owner's account by forcing a denial of access, such as denial of service (DOS). For example, a hacker can try multiple login attempts to access an account until a threshold number of attempts occurs, after which access to the account is denied. A genuine owner of a locked account may have to perform several steps to unlock the account. Denial of access to important accounts, such as a VPN account or an administrative account, can cause significant loss of use of the account and inconvenience to the genuine owner of the account.